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REMARJKS/ARGUIVIEINrXS 

This Amendment and the following remarks are intended to fully respond to the Final 
Office Action mailed June 23, 2006. In that Office Action claims 1-23 were examined, and all 
claims were rejected. More specifically, the specification is objected to, claims 18 and 19 were 
rejected under 35 U.S.C. § 1 12, first paragraph, as failing to comply with the written description 
requirement; claims 18 and 19 were rejected under 35 U.S.C. § 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention; and claims 1-23 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over IPSEC, "Minutes of IPSEC Working Group Meeting", in view of ICent 
et al., "Fragmentation Considered Harmful". Reconsideration of these rejections, as they might 
apply to the original and amended claims in view of these remarks, is respectfully requested. 

In this Response, claims 1, 3, 6, 10, 14, 18, 20, and 22 have been amended; claims 4, 5, 9, 
19, and 21 have been canceled; and no new claims have been added. Therefore, claims 1-3, 6-8, 
10-18, 20, and 22-23 remain present for examination. 

Specification 

The specification is objected to as failing to provide proper antecedent basis for the 
claimed subject matter. The examiner states: 

Claim 18 comprises the limitation "wherein the steps of generating, determining 
and fragmenting are performed independently of performing any steps on the data 
packet corresponding to a transport layer protocol and/or a network layer 
protocol " The specification fails to provide proper antecedent basis for this 
limitation. 

6/23/2006 Office Action, p. 2, "Specification/* 

Claim 1 8 has been amended to remove the referenced limitation and thereby rendering 
the objection moot. Claim 1 8 is believed to be allowable and accordingly, applicants request 
withdrawal of the objection. 
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Claim Rejections — 35 U.S.C. § 112 

Claims 18 and 19 were rejected under 35 U.S.C. § 1 12, first paragraph, as failing to 
comply with the written description requirement. Amended claim 1 8 is fully supported by the 
specification. Claim 19 has been canceled. 

Claims 18 and 19 were rejected under 35 U.S.C. § 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. Amended claim 18 contains no ambiguities. Claim 19 has 
been canceled. 

Claim Rejections — 35 U.S.C § 1Q3 

Claims 1-23 were rejected under 35 U.S.C. § 103(a) as being unpatentable over IPSEC, 
"Minutes of IPSEC Working Group Meeting" (hereinafter "IPSEC"), in view of Kent et al., 
"Fragmentation Considered Harmful" (hereinafter "KLent"). 

Claim 1 discloses generating and transmitting an IKE packet over a network; 
determining whether a response to the IKE packet was received; fragmenting the IKE packet into 
a plurality of smaller packets when a response is not received. Neither IPSEC nor KLent, nor 
their combination, teaches or suggests using the absence of a response to an IKLE packet to 
determine whether to fragment IKLE packets. IPSEC teaches fragmenting IKLE packets above the 
UDP level, but does not disclose any specific method of determining when to fragment IKLE 
packets. KLent does not remedy this deficiency in IPSEC. KLent discloses details of how to 
fragment data packets, but does not disclose the transmitting and using the absence of a response 
to a packet to determine whether to fragment packets before sending them. While KLent teaches 
determining whether fragmentation has occurred in the IP layer and further fragmenting a 
datagram in response to determining that fragmentation has occurred, KLent does not teach or 
suggest basing the decision to fragment an IKLE packet on whether or not a response to a 
transmitted IKLE packet has been received, regardless of whether fragmentation has actually 
occurred in the IP layer. Thus, the combination of IPSEC and KLent fails to teach or suggest a 
method of transmitting Internet KLey Exchange (IKLE) data packets across a network comprising, 
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inter alia, generating and transmitting an IKE packet over a network; determining whether a 
response to the IKE packet was received; fragmenting the IKE packet into a plurality of smaller 
packets when a response is not received p , as described in claim 1 . 

In view of the foregoing, claim 1 patentably distinguishes over IPSEC in view of Kent. 
Accordingly, Applicants respectfully request that the rejection of claim 1 under § 103(a) be 
withdrawn. Claim 2 depends from claim 1 and is patentable for at least the same reasons. 
Accordingly, Applicants respectfully request that the rejection of claim 2 be withdrawn. 

Amended claim 3 discloses fragmenting IKE data packets wherein the fragmenter 
module does not split the IKE data packets unless no response to a previously-sent IKE data 
packet has been received. As explained above, neither IPSEC nor KLent, nor their combination, 
teaches or discloses using the absence of a response to an IICE data packet to determine whether 
to fragment future IICE data packets. Thus, amended claim 3 is patentable for at least the same 
reasons as claim 1. Accordingly, Applicants respectfully request that the rejection of claim 3 be 
withdrawn. 

Amended claim 6 discloses a method for receiving fragmented IICE data packets that 
includes, inter alia, determining the total size of all fragments that contain the same identifier 
and discarding said fragments when the total size exceeds a predetermined limit. This limitation 
was previously submitted as claim 9, now canceled. The Examiner rejected this claim on the 
grounds that it was unpatentable over IPSEC in view of ICent, citing Kent section 2.4, par. 3. 
Applicants respectfully traverse this rejection. KLent teaches discarding all fragments that contain 
the same identifier when a receiving buffer is full and fragments from two different data packets 
have been received. KLent does not teach or suggest determining the total size of all fragments 
that contain the same identifier^ nor does it teach or suggest discarding said fragments when the 
total size exceeds a predetermined limit. IPSEC does not remedy this deficiency in KLent. As 
discussed above, IPSEC merely teaches fragmenting an IKLE data packet above the UDP level. 
IPSEC does not discuss any details of fragmentation or handling of IICE data packets or 
fragments. Thus, the combination of IPSEC and KLent fails to teach or suggest a method for 
receiving fragmented Internet KLey Exchange (IKLE) data packets comprising, inter alia, 
determining the total size of all fragments that contain the same identifier and discarding said 
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fragments when the total size exceeds a predetermined limit. 

In view of the foregoing, amended claim 6 patentably distinguishes over IP SEC in view 
of ICent. Accordingly, Applicants respectfully request that the rejection of claim 6 under § 103(a) 
be withdrawn. Claims 7, 8, and 10 depend from amended claim 6 and are patentable for at least 
the same reasons. Accordingly, Applicants respectfully request that the rejection of claims 7, 8, 
and 1 O be withdrawn. 

Amended claim 1 1 discloses a system for transmitting IKE data packets comprising, inter 
alia, means for initializing, operating, and monitoring a timer; means for detecting whether the 
IKE packet was successfully received at the intended receiver node before the expiration of the 
timer; and means for fragmenting the IKE packets into smaller packets when the IKE packet was 
not successfully received at the receiver node before the expiration of the timer. Neither IP SEC 
nor ICent, nor their combination, teaches or discloses the use of a timer to determine whether to 
fragment IKK data packets. IPSEC teaches fragmenting IKE packets above the UDP level, but 
does not disclose using a timer or any other specific method of determining when to fragment 
IKE packets. Kent does not remedy this deficiency in IPSEC. Kent discloses details of how to 
fragment data packets, but does not disclose the transmitting end using a timer to determine 
whether to fragment a packet before sending it. Instead, Kent teaches the receiving end using a 
"Time To Live" flag to determine whether to discard a packet that has already been received and 
stored in a buffer. (Kent, section 2.1 .) While Kent teaches determining whether fragmentation 
has occurred in the IP layer and further fragmenting a datagram in response to determining that 
fragmentation has occurred, Kent does not teach or suggest basing the decision to fragment an 
IKE packet on whether a timer has expired before receiving a response to a transmitted IKE 
packet, regardless of whether fragmentation has actually occurred in the IP layer. Thus, the 
combination of IPSEC and Kent fails to teach or suggest a method of transmitting Internet Key 
Exchange (IKE) data packets across a network comprising, inter alia, initializing a timer; 
determining whether a response to the IKE packet was received before the expiration of the 
timer; fragmenting the IKE packet into a plurality of smaller packets when a response is not 
received before the expiration of the timer , as described in amended claim 1 1 . Accordingly, 
Applicants respectfully request that the rejection of claim 11 be withdrawn. 
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Claim 12 depends from amended claim 1 1 and is patentable for at least the same reasons. 
Accordingly, Applicants respectfully request that the rejection of claim 12 be withdrawn. 

Claim 13 discloses a method of transmitting data packets across a network including, 
inter alia, generating and transmitting an Internet Key Exchange (IKE) packet over a network; 
determining whether a response to the IKE packet was received; and fragmenting the IKE packet 
into a plurality of smaller packets when a response is not received. As explained above, neither 
IP SEC nor KLent, nor their combination, teaches or discloses using the lack of a response to an 
IICE packet to determine whether to fragment future IICE data packets. Thus, claim 1 3 is 
patentable for at least the same reasons as claim 1 . Accordingly, Applicants respectfully request 
that the rejection of claim 13 be withdrawn. 

Amended claim 14 and claims 15-17 depend from amended claim 13 and are patentable 
for at least the same reasons. Accordingly, Applicants respectfully request that the rejection of 
amended claim 14 and claims 15-17 be withdrawn. 

Amended claim 1 8 discloses a method for transmitting data packets across a network 
comprising, inter alia, initializing a timer and determining, based at least in part on the 
expiration of the timer, whether fragmentation of the data packet is necessary to successfully 
transmit the IKE information over a network. As explained above, neither IP SEC nor KLent, nor 
their combination, teaches or discloses the use of a timer to determine whether to fragment I ICR 
data packets. Thus, amended claim 1 8 is patentable for at least the same reasons as amended 
claim 1 1. Accordingly, Applicants respectfully request that the rejection of claim 1 8 be 
withdrawn. 

Amended claim 20 discloses a method for resolving transmitting errors associated with 
transmitting IICE packets including, inter alia, initializing a timer; determining, based at least in 
part on the expiration of the timer, whether it is necessary to fragment the IKE data packet; 
fragmenting the packet, if necessary, with a code module that does not implement the TCP, XJDP, 
or IF* protocols before the packet is processed by a code module that does implement the TCP, 
UL>P or IF* protocols . As explained above, neither IPSEC nor ICent, nor their combination, 
teaches or discloses the use of a timer to determine whether to fragment IICE data packets. Thus, 
amended claim 20 is patentable for at least the same reasons as amended claim 1 1 . Accordingly, 
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Applicants respectfully request that the rejection of claim 20 be withdrawn. 

Amended claim 22 discloses a method of efficiently managing resources by intelligently 
discarding fragments of 1 ICR data packets, comprising, receiving a plurality of fragments of a 
single IKE data pachet, wherein the fragments were transmitted from a transmitting node in an 
order that can be determined from information contained within the received fragments ; 
determining from information contained within the received fragments whether any of the 
received fragments have been received in an order that differs from the order in which the 
fragments were transmitted from the transmitting node; and discarding at least certain of the 
received fragments when a predetermined number of out of order fragments from a single IKE 
data packet have been received. Kent teaches discarding all fragments corresponding to a first 
IKE data packet if fragments corresponding to a second IKR data packet are received and the 
receiving buffer is full. (Kent, section 2.4, par. 3.) ICent does not teach or suggest determining 
whether the order in which fragments corresponding to a single IKE data packet were received 
corresponds to the order in which those fragments were transmitted. Neither does Kent teach or 
suggest discarding at least certain of the received fragments when a predetermined number of 
out of order fragments from a single IKE data packet have been received. IP SEC fails to remedy 
this deficiency of Kent. Thus, the combination of IPSEC and Kent fails to teach or suggest all of 
the limitations of amended claim 22. 

In view of the foregoing, amended claim 22 patentably distinguishes over IPSEC in view 
of Kent. Accordingly, Applicants respectfully request that the rejection of claim 22 under 
§ 103(a) be withdrawn. Claim 23 depends from amended claim 22 and is patentable for at least 
the same reasons. Accordingly, Applicants respectfully request that the rejection of claim 23 be 
withdrawn. 

Conclusion 

It is believed that no further fees are due with this Response. However, the 
Commissioner is hereby authorized to charge any deficiencies or credit any overpayment with 
respect to this patent application to deposit account number 13-2725. 

In light of the above remarks and amendments, it is believed that the application is now 
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in condition for allowance and such action is respectfully requested. Should any additional 
issues need to be resolved, the Examiner is requested to telephone the undersigned to attempt to 
resolve those issues. 

Respectfully submitted, 



Dated: 



27488 

PATENT TRADEMARK. OFFICE 



5cott Weitzel, #54^34 x 
MERCHANT & GOULD P C. 
P.O. Box 2903 

Minneapolis, MNf 55402-0903 
303.357.1648 
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